perm filename USERS.OLD[RDG,DBL] blob
sn#628606 filedate 1981-12-08 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00010 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 ∂15 Oct 1980 1102-PDT <CHT at SU-AI> RLL
C00003 00003 ∂05-Nov-80 1342 SASTRY at USC-ISIF RLL applications
C00005 00004 Contact with Keirsey@ECL
C00017 00005 UICC's interest
C00033 00006 ∂ 2 Feb 1981 2205-PST Student1 RLL-1
C00035 00007 Messages with Larry Hines - at UofTexas, Austin
C00049 00008 (conversations with Steve Tappel)
C00051 00009 Messages with Jonathan King @ HP
C00053 00010 Messages with Steve Tepper (Greep) - Rand, Stanford
C00055 ENDMK
C⊗;
∂15 Oct 1980 1102-PDT <CHT at SU-AI> RLL
To: csd.greiner at SU-SCORE
I've been trying to use RLL on SCORE and must not be getting the right files on the right directory; or perhaps I need a password? In any cae, if you could tell me how to get started, I'd really appreciate it. Sorry I didn't stop by yesterday for a
demo. . .I decided I really wasn't clear enough yet on what I wanted to ask you. So
if you could just send instructions on starting, I'll take it from there for a
while. Thanks Russ!
Chris
∂05-Nov-80 1342 SASTRY at USC-ISIF RLL applications
To: greiner at SU-AI
Hi,
I obtained a copy of the paper describing RRL-1. Thankyou. Mentioned in it is
a reference to some work on applications of RLL to VLSI layout. I am also
interested in this although I have not done any real work along this path.
What I would like to know is what problem is being looked at and what has
been done.
Could you send me any info concerning this or direct me as where I amy obtain
such information ?. Thanks again.
Sarma Sastry. (Sastry@USC-ISIF)
-------
Mailed to SASTRY, STEFIK@PARC&HBOWN@SCORE/cc 16:49 5-Nov-80
VLSI/RLL interconnections
Mark Stefik (STEFIK@PARC) and Harold Brown (CSD.HBROWN@SCORE) are
currently building a system which will help plan and design VLSI layout.
(According to Mark, ISI's Danny Cohen knows all about it.)
I sent them a copy of your message.
Russ
Contact with Keirsey@ECL
∂13-Oct-80 1226 TOB
To: ROD, DLO, BIS, SL
Bruce
That's an excellent letter. Thanks for the support.
Tom
∂13-Oct-80 0155 BULLOCK at USC-ECL SAIL/MACLISP image processing software
Date: 13 OCT 1980 0154-PDT
From: BULLOCK at USC-ECL
Subject: SAIL/MACLISP image processing software
To: Druffel at ISI
cc: tob at SAIL, bullock
I have been talking to Tom Binford lately about getting a copy of the
MACLISP based software kernel that he has been developing for image
understanding work. I mentioned to Tom that I would send you a
note letting you know of our interest in using some of the
you have supported.
Put simply, our work has undergone a long process of evolution. In 1973 our
first scene analysis software package was implemented in LISP 1.6 and was
used to support work on rule based control structures for scene analysis
for several years on an AFOSR grant. With the change in funding policy
about that time to emphasize work more directly related to military
applications, the main line of our activity shifted from general system
investigations to applied work on problems like target cueing and image
based terminal navigation. Although I built one system for texture
analysis in SAIL while I was at Stanford during this
period, most of the systems we built from then on were in FORTRAN. The shift
to FORTRAN was more practical than scinentific and had to do with
compatability with funder supported computers and better availability of
programmers. Starting about two years ago there was a new move
towards systems that for the first time were fairly
complex and some were even rule based (again!) at the control level. This
new generation was enough to justify finally dumping FORTRAN and trying
a switch to another language. For a number of resons, Pascal was
chosen. Several systems, including one with a rule based interpreter,
were implemented on both the PDP-10 and on the VAX. For a number of reasons,
some of the most important involving memory management and automatic
garbage collection, Pascal proved to be a poor implementation language both
for image analysis software and rule based systems. This brings us up to
about the current point in time. A number of other languages have been
evaluated. For straight image processing one of the best seems to be "C".
The situation is now more complex however, because for the first time
we are planning the construction of systems that have a much greater
demand for rule based/kbs components. For example, in the case of
smart weapons this is especially true. Independently of our image based
work we have been using Interlisp for some KBS application studies
envolving EMYCIN and some systems of our own. Both folklore and some
experiments of our own have shown that Interlisp is certainly
not the common denominator link between AI/KBS/and IU that one might hope
for. At the same time as our experience with KBS systems such
as EMYCIN has increased and our application interests have become more
specialized and complex we have realized that we will probably have
to do alot of our own system crafting to get
what we really wnat. Thus, except for some of the new tools like RLL,
there is no strong reason to stick with Interlisp if we are not going
to use a canned system
like EMYCIN.
All of this finally brings us to Tom's system. Here it looks like we
can build the type of complex image analysis system we need, with
compatability with rule based systems all in one environment. The kernel
operations in his system will probably allow us to go off in our slightly
different direction of hybrid IU/KBS systems but with a good IU starting
point. Also, unlike 1973 when we were apushing to
keep working in LISP 1.6 with little success, the mood has changed
significantly, as you are well aware. I think we can make (and probably
will) arguments that because of the advancement in LISP implementations
that emphasize efficiency and hardware such as the
LISP machine movements and VHSIC technology that it is also "practical"
for us to consider a major reorientation and emphasis to LISP based
software.
So, to bring this long story to a close. For the many
reasons outlined above, we are seriously interested in a LISP based
system for our future work. At the same time Tom's system looks to
have excellent ppossibilities
for what we want. The implementation looks to be one of the best, system-wise,
around and the results from his work based on the software are very impressive.
We have expressed our interest to Tom and look forward to acquiring the
parts of his system that would be needed for our work. If such a transfer
is successful, I will keep you posted of our progress. We will also
be happy to acknowledge the source of the kernel in terms of Tom,
Stanford, and DARPA.
Bruce Bullock.
-------
∂10-Nov-80 1401 KEIRSEY at USC-ECL Details
To: RDG at SAIL
cc: keirsey
I have read your paper on the Details of RLL. On the whole I thought
it was good. Unfortunately, I had the naive notion that RLL-1 would be
simpler in conception and implementation. As I read it, I got a feel
for how you represented some things, but it is clear to me that real
understanding of a particular knowledge base will only come through
use. One important issue to me is how one can understand another
person's knowledge base (given that they are large). Do you have any
thoughts on this?
I have a very detailed question. On Diagram 1 of Details of RLL, what
is the significance of the AND-node notation (AnyConcreteThing&Unit,
AnySlot)?
-------
∂Mailed to Keirsey@ECL 17:37 11-Nov-80
Possible Answers
First, to answer the easy question:
In general the subclasses form a DAG, as opposed to a tree.
The "AND-notation" you asked about means that those particular subclasses
are disjoint.
As to your other inquiries:
You are correct in expecting the ideas of a rll to be simple.
The document you received described a particular implementation, slanted
towards things which I thought were relevant. Furthermore, many of the
details presented reflected facets which seemed
appropriate a while back; and which have not yet been updated to a better,
cleaner form.
Prof Genesereth, in writing up his description of MRS
has stressed the simplity of its design. I recommend that paper
(HPP-80-24) to confirm the accuracy of your intuitions.
Yes, Prof Lenat & I have worried quite a bit about the question of how
to insure that each KB is understandable and unambiguous.
We considered using a predefined formal specification,
(such as predicate calculus),
and rejected these as too hard to understand, and not perspicious enough.
The sub-section 4.4 of the AAAI paper (on pages 167-168) describes another
approach - using a "Semantics" slot for each slot-unit, telling what this
slot "really" means. The "Meta-Description & Modifiability" memo (HPP-80-18)
by Lenat & Genesereth, elaborates these ideas.
If this doesn't answer your questions, let me know and I'll try again.
Russ
UICC's interest
Mailed to THORPE@CMUA 13:58 31-Oct-80
U of I @ CC
Jack Mostow suggested you might be able to answer a question I have about
the University of Illinois at Chicago Circle. Is it on any computer
network? In particular, is it on any of the networks which (you know to)
include Stanford - such as the ARPAnet, or SUMEX. (I checked out the
ARPAnet, but could not find it there - does it have perhaps some cryptic
designator?)
Thank you.
Russ Greiner
(I am trying to send a message to Prof Minkowycz and A. Sharma.)
∂31-Oct-80 1518 Charles.Thorpe at CMU-10A (C410CT60) Re: U of I @ CC
Date: 31 October 1980 1750-EST (Friday)
From: Charles.Thorpe at CMU-10A (C410CT60)
To: Russell Greiner <RDG at SU-AI>
Subject: Re: U of I @ CC
In-Reply-To: Russell Greiner's message of 31 Oct 80 16:58-EST
Message-Id: <31Oct80 175047 CT60@CMU-10A>
The only Chicago organization I could get to admit to having ARPAnet connections
was Argonne National Labs, and they're a long ways away from Circle campus. I
don't know about the other nets. Sorry I couldn't be of more help.
Chuck Thorpe
PS--greet Jack for me.
Mailed to THORPE@CMUA 15:50 31-Oct
Thanks anyway.
Do you know anything about the research Minkowycz et al are pursuing?
Russ
∂01-Nov-80 1210 Charles.Thorpe at CMU-10A (C410CT60) Re: Thanks anyway.
Date: 1 November 1980 1507-EST (Saturday)
From: Charles.Thorpe at CMU-10A (C410CT60)
To: Russell Greiner <RDG at SU-AI>
Subject: Re: Thanks anyway.
In-Reply-To: Russell Greiner's message of 31 Oct 80 18:50-EST
Message-Id: <01Nov80 150726 CT60@CMU-10A>
Sorry, I don't know anything about Minkowycz. My only dealings with the U of
Chicago were in trying to get an ARPA link to CMU; I never actually attended
there.
Chuck
Mailed to THORPE@CMUA 13:13 1-Nov
OK
Oh, Jack wasn't sure what your affiliation with UofI@CC was.
Russ
!Mailed (by Post Office) 3 November
1 November 1980
Professor W.J. Minkowycz
Dr. A. Sharma
University of Illinois at Chicago Circle
College of Engineering
Box 4348
Chicago, Illinois 90980
Dear Sirs:
I am pleased to learn of your interest in the RLL-1 system, as expressed
in your letter of 10 October. I am sending, under seperate cover, the
memos you (explicitly) requested, together with two other potentially
relevant ones. The "Details of RLL-1" report includes many low-level
specifics of our current system.
While we do plan to release RLL-1 eventually, we are cautious about
releasing it too soon. Our reasons stem from various causes:
(1) The particulars of the starting RLL-1 system (i.e the "bootstrap") are
still being hammered out. The difficulties of this design are in two
camps: First we want the system to be as unbiased as possible. Given
that this starting system will necesarily employ some conventions we want
to insure each such convention is "minimal" and necessary -- that is, they
should not force you, the user, into difficult situations or awkward
coding. The neo-natal MRS (described in more detail below) is much closer
to realizing this goal that RLL-1 will ever be.
Secondly, RLL-1 should come equipped with enought powerful, general
constructs that the user can readily do a great many useful things, over a
wide range of tasks. Bifucating again, many of RLL-1 current components
have not yet reached the generality we think possible, and furthermore,
there are many areas which have not even been considered, and so the
modules capable of performing this type of task have not yet been built.
This is not surprising: By design, RLL-1 is a continuously growing and
evolving system -- one capable of adding on new components as the need
arises. The concern here is the large number of known ommissions.
(2) Another major problem is the bugs which are present in the current
RLL-1 system. We feel it will take about a month to correct the ones we
now know about.
(3) The other major issue stems from research directions. Prof Lenat and
I developed RLL-1 as a tool, to be used to build the EURISKO system. [See
Appendix B.2 for an overview of RLL-1's role as foundation for this
system. There were two major reasons why we encouraged others to use
RLL-1: First, these other applications will push on the set of features
RLL-1 will have to provide; the modules built to handle such situations
will expand RLL-1's capabilites, making it a more general tool for our
uses as well. Second, RLL-1 will provide a Lingua Franca for
EURISKO-related knowledge bases. To function, the EURISKO system must
first include a large collection of diverse knowledge bases. Rather than
inputing these ourselves, we would rather develope a symbiotic relation
with other researchers -- they will be given the underlying EURISKO
system, as a particular representational/control scheme for their data,
and in exchange, we get to peak over their shoulders, and collect their
set of heuristics. As such, it is strongly in our interest to continue
supporting EURISKO. We have further decided to support/improve RLL-1 only
where such modifications are crucial to its application to this primary
line of research -- which is concerned more with heuristics than with
representations, per se.
The research ideas of a representation language language are still being
pursued here at Stanford, by Professor Micheal Genesereth and David Smith.
They are now developing the MRS (for Modifiable Representation System)
mentioned above. They have guaranteed continued support of its kernel,
and intend to soon develop a full user community, in which implementations
of diverse representational systems can be coopertively constructed,
collected and dispersed. After the (both conceptual and implementation)
bugs have been purged from both of our respective systems, RLL-1 will
actually be encoded in MRS. At this point RLL-1 will be (viewable as) one
of many "plug-in" modules, which "twiddles" that copy of MRS into a system
which follows a particular set of conventions.
With these caveats in mind, here are the options for using RLL-1, as I see
them:
(1) We could export to you the RLL-1 system, as it is now. We would, of
course, make no commitment to support this pre-release version. It is,
however, thoroughly documented, and does do a great number of things
correctly.
(2) In about another month (after removing those major known bugs) we plan
to freeze the then-existent system. This system will be fairly static --
the only updates will be repairs to bugs subsequently found, as opposed to
extensions. Note that we will fix just those problems which seem to lie
on our critical path.
(3) The EURISKO network is just starting up -- within a few months after
getting a working version of RLL-1, we feel it will be distributable. If
your task area is conducive to a EURISKO type of exploration, you will be
welcome to use that system. Recall that this network, which will be built
on top of RLL-1, will continue to be supported from here.
(4) If you wish to pursue representation issues, qua research topic, you
may wish to join the growing RLL-1/MRS community. "Good citizens" of this
group are expected to contribute both ideas and code to an evolving,
improving system.
Let me know which of these options seems most appropriate -- or perhaps
you can envision another possibility.
I have a quick list of remaining issues/questions:
1. Your letter refered to a description of your task. Could you perhaps
send me another copy of this article, as I never found it.
2. Is UofI@CC on any computer network which also includes Stanford? Do
you know of any (even indirect) electronic path from there to here? I can
be reached at RDG@SU-AI, CSD.GREINER@SCORE or GREINER@SUMEX; and much
prefer this faster communication to the slower postal mail.
3. I am enclosing a copy of the first (and only) message posted on the
(Virtual) RLL Bulletin Board. If you wish, I will see that you receive
further messages as well. (Note this bulletin board is intended to
discuss theoretical issues of representation language langauges, as
opposed to our implementation, RLL-1, per se. Notications of
updates/modifications/bugs/etc to RLL-1 will appear elsewhere.)
4. RLL-1, as it now stands, does require InterLisp. MRS, however, will
have parallel implementations in both InterLisp and MacLisp. Thus once
RLL-1 has been written in MRS it will be MacLisp compatible.
This has been the first formal request for RLL-1, from outside of
Stanford. As such the policies concerning how to distribute this system
are quite flexible. If you have any suggestions on how we should
facilitate releasing our system, please let me know. Please let me know,
also, if there is any way I may be of further help with your project.
Sincerely,
Russell Greiner
Computer Science Department
Stanford University
Stanford, CA 94305
CC: Professor Douglas B. Lenat, Professor Micheal R Genesereth, David E
Smith
!∂02-Nov-80 2014 CSD.LENAT at SU-SCORE Re: Comments before I mail this off?
Date: 2 Nov 1980 2011-PST
From: CSD.LENAT at SU-SCORE
Subject: Re: Comments before I mail this off?
To: RDG at SU-AI
In-Reply-To: Your message of 1-Nov-80 1437-PST
An ecellent answer; much bette than I'm sure they're expecting. Thanks.
Doug
-------
!∂05-Nov-80 1020 CSD.SMITH at SU-SCORE Re: FYI
Date: 5 Nov 1980 1017-PST
From: CSD.SMITH at SU-SCORE
Subject: Re: FYI
To: RDG at SU-AI
In-Reply-To: Your message of 4-Nov-80 1806-PST
You should probably ask Ed or Bruce about distribution. I think that Stanford
requires that a copyright notice go out with the software, and may also require
that a liability release form be signed.
-------
∂ 2 Feb 1981 2205-PST Student1 RLL-1
To: GREINER
I have just finished your "working paper" on RLL-1 and would be interested
in learning more about it and, perhaps, experimenting with it as it may be
applied to a project on which I am working. Briefly, I am building a Neuro-
anatomy/Anatomy knowledge base which I hope to be able to use as a reference
for the INTERNIST programs as well as for the basis of a Neurological Dia-
gnosis and teaching package. The relational aspects of functional neuro-
anatomy and the limitations of the current system (which utilizes a series
of related hashfiles), have prompted me to look to see how others have
tackled the problems of knowledge base management. To this end, I have
already contacted Mark Stefik about the UNITS package, and while exploring
that area, I came across your paper. If you could direct me to sources
of additional information on RLL-1 I would greatly appreciate it. I would
also, of course, be interested in current applications of RLL-1 some of
which you mentioned in the paper.
Thanks for your time.
Sean McLinden
<STUDENT1>@SUMEX-AIM
Messages with Larry Hines - at UofTexas, Austin
[Discussed ephemeral units]
∂06-Apr-81 1939 ATP.HINES at UTEXAS-20 RLL and theorem proving
To: RDG at SU-AI
cc: CSD.LENAT at SU-SCORE
I think that I have finally develop a theorem prover system which will benefit
from being implemented in RLL. However, only a small kernal of the
knowledge base's templates have been created. Other frame types have suggested
themselves and, doubtlessly, eventually even more types will be necessary.
I apologize for having to reask this, but I would like to be able to
<make>
all frames, not marked as permanent, to disappear upon the end of a
session.
Anyway, since I have now finally learned a way to use RLL, I would like
to obtain a copy of it. I am addressable through the APRANET as
ATP.HINES@UTEXAS20 or at least I been told that I am.
larry hines
-------
!∂Mailed to ATP.HINES@UTEXAS-20 (CC DBL) 14:07 13-Apr
Answers, sorta
Larry -
Good to hear from you again. I hope all is well over in Texas.
To answer your questions:
There are several ways to deal with "ephemeral" units, each with its own
set of complications.
Solution 1
Every unit which descends from AnyEphemeral will be wasted at
the end of each session. This is the method I have used for handling such
temporary entities, as it is the safest and most effective.
These wins are not free, though. As you might imagine, closing and writing the
networks will be expensive in time. Furthermore, as these entities are
full-fledged units, creating and initializing each may well take longer
than you'd like. A speed up of, maybe, a factor of 4 or 5 will come about
by judicious use of macros, but there is simply so much work which has to
take place...
Solution 2
You could avoid much of the time-to-close-the-KBs expense by storing
all ephemerons in some garbage KB, which is simply CANCELled at the end of
each session, rather than WRITEten. The problem here is the plethora
of un-updated back-pointers. (IE other units may still point to a now
destroyed temporary unit, causing grief in many situations.) Still, if
you could tolerate this, this solution will be the fastest, and least
cautious.
Solution 3a.
Of course, this is not unsolvable: If you knew which slots might so connect
temporary with permanent units, you could instruct each such slot to
record each connection made; and then quickly map thru these when ending
a session, removing the soon-to-be-offending links.
This will be time-consuming, both during PUTs and when closing things, but
potentially faster than the time loss implied in Soln 1.
Solution 3b
Yet another infinitely-conservative possibility, (along the lines suggested
by Soln 2 above) would be to spend
some time at the start of each session, to remove all offensive links from
the existing units.
----
The decision of which of these is most desirable is where it belongs: in
lap of the user. You the user get to consider what requirements your
task will impose of your system, and build the system accordingly --
ie if you can stand some slop, but prefer your program to be fast,
solution 2 may be best. On the other hand, you may have some idea for
some intermediary system, incorporating some combination of, say 1 and 2
above. Great - as soon as you implement it, it'll be incorporated into RLL
for the next user.
Final note: realize you're not fighting RLL here -- only the specifications
of your task. To permit such flexibility.
RLL never commits itself with respect to temporary units.
-----
Next issue: How to get you on RLL. This is tricky; as RLL is still
(to be kind) buggy. I would have no objection to mailing you a copy
(or actually, permitting you to FTP it), but realize there are many things
which will not work, and there are many remaining holes.
Let me what I can do for you.
Russ
PS I've sent you (ATP.HINES@UTEXAX) several messages, earlier in the year.
(About your SCORE account, and the RLL bulletin board, ...)
Did any other them get thru?
!∂16-Apr-81 0131 ATP.HINES at UTEXAS-20 Getting RLL,etc.
Greetings Russ,
All is well. At least as far as I can tell, it is.
It's the same with you, I hope.
Thanks for the advice on "ephemeral" units. My initial guess is that
solution 2 (i.e. garbage KB) is what I'll use; although, AnyEphemeral units
will probably be required, too.
I don't have a major preference as to which way (FTPing or mailing)
RLL uses to get here. If I FTPed RLL it is likely that I would get it
sooner and be easiest on you. I was wondering how much space RLL takes.
About your messages to me in Sept., I did get them all (I think) albeit
belately. If the RLL bboard is still active, I would like to be on it, if
that is possible.
By the way, say hi to the bozos from the texas boy.
-- larry
!∂Mailed to Hines (CC DBL, DE2) 15:51 24-Apr
Undaunted, into the fray
Glad to see you're still interested. The current version of RLL is now on
Rand-AI's machine. (One fringe benefit of consulting there was unlimited
access to that marvelously unloaded machine.)
As usual, RLL is a mere epsilon increment away from respectibility, and
hence releasability. (I'm now twiddling with MACROs, which, I hope, will
speed up its operations a good order of magnitude.)
Its outward appearance hasn't changed much since last summer; that's
pretty much by conscious design. It has absorbed a fair number of modules
-- mostly concerned with EURISKO, and encoding information about LISP
functions.
Space...
First, RLL is dependent on CORLL, which takes up a fair amount of space.
You may wish to store a CORLL sysout on some public directory -- not only
does this permit others to use this reasonably well documented, (and
possibly useful) tool, but it also spares you from absorbing the cost of
this disk space. Anyway, this will consume about 300-400 pages.
Now for RLL: There are currently several essential KBs, each of which
contains a *.KB file, plus an optional *.. and *.COM pair of files for the
associated LISP functions. Just in static storage requirements, these
will cost about 600 pages. Your dynamic storage should be almost this
much again, for the *.PAGE temporary files. (Note you may not have to
worry about this... In fact, there are only a few cases when it makes any
differences:
(1) if you're system is as stingy as SCORE, which does not permit you any
storage over your allocation, even for an instant; or (2) if you want to
preserve your state using a SYSOUT, in which case you'll have to store
these "temporary files" from one day to the next. In the latter case you
will need not only the 4 to 5 hundred pages for the PAGE files, but an
additional 300 pages for the actual sysout as well.
The figures above refer only to the nucleus required for RLL to run. You
may, in addition, want to utilize other existant KBs -- and of course this
will cost you space. Of course, you will be creating your own "theorem
proving" KBs as well. I have no real idea how much space this will
require -- except to say that whatever you estimate now, I can state from
experience, will not be enough.
Politics and Policies ...
I've got no objections to handing over RLL, as it stands now. There are
some caveats: As I've mentioned before, it's got its share of bugs and
problems; and I've no yen to fix them twice. Which leads to problems: who
will maintain your version? How should I communicate the errors and fixes
found? Perhaps I could periodically mail over new versions of the nuclear
files -- but that would force you to reconnect the units of your nascent
KBs to these time and again. That may just amount to running the
"reconnecting" code each time - which is easy to do, if time consuming.
Of course that may not work. There is a mechanism for sending along
single now-fixed units... maybe that's what I should do? Comments? (Now
is a good time for me to resolve this issue, as I've been promising to
release this system for months now...)
The other issue is Stanford. Nobody here minds releasing the software;
but there seems some worry that you might make a buck on it, and not give
Stanford its share. Sooo, I got a little form I have to have you fill
out.
Comments, critiques, indications of disgust?
Russ
!∂01-May-81 1743 ATP.HINES at UTEXAS-20 daunted, into the fray
Gee, the fray is big.
Well it seems that at the present time finding the space that RLL needs is
not going to happen. At least until out system is augmented by a couple more
disk packs (about four months + delivery delay time from now), I am not going
have a home for RLL.
Gee, even the best laid plans ... .
As I'm sure you know, Doug Lenat will be here Monday so I'll speak to
him on this.
larry
-------
(conversations with Steve Tappel)
∂31-Jul-81 1605 STT Nancy and perspectives
The mystery is solved. I just got a postcard from Nancy, she left on short
notice to Phoenix, Arizona (vsiting family I presume) and says she'll be
back the first week in August.
I'd like to meet with you sometime soon, say early next week, to talk about
perspectives and views. I'm trying to put my reformulation stuff into a more
general framework, especially, what does it correspond to in non-mathematical
domains? The line I am taking is to consider a formulation as a special case
of a view, where a view of an object is basically a set of features (slots) of
the object. Reformulation then corresponds to changing one's view, to better
adapt it to one's current purpose. A "perspective" seems to be some
sort of meta-view, telling one which features go together to make a coherent
view. Well anyway, you have thought some about perspectives and views and
may be able to help me sort this out.
Messages with Jonathan King @ HP
-- Mailed him the following messages:
∂06-Apr-81 1612 Steve Klein <SKLEIN at USC-ISIB> Re: Yak, Yak, Yak
∂01-May-81 1745 Steve Klein <SKLEIN at USC-ISIB> A Test of Wizardry
∂To SKLEIN@ISIB (18:11 20-May)
∂TO SKLEIN@USC-ISIB 16:43 22-June
-- real contacts:
∂TO JJK 15:43 24-Jul
Where it's at
Jonathan:
The file JJK[rdg,dbl] has some of my messages with Steve Klein --
I printed you a copy (left in the G mailbox); or feel free to examine it
on line.
Sorry it's so chatty -- Steve and I have known each other for 8 years now...
Russ
∂24-Jul-81 1732 JJK via SU-TIP
THANKS, I'LL PICK UP THE LISTING.
∂TO JJK 13:31 28-Jul
RLL Tutorial-ette
Jonathan:
Looks like Steve Klein, from ISI, will be coming next week,
circa Monday. I plan to just give him an informal run through of RLL,
(spending only, say, part of Monday),
and let him then attack his particular task.
Would you like to sit in on some of the seesions -- in particular
the first one?
The actual time is still up in the air. I'd prefer late morning,
around 11; but Steve may just be arriving then. Do you have any preferences?
Russ
Messages with Steve Tepper (Greep) - Rand, Stanford
∂TO GREEP@SCORE, GREEP@Rand-Unix 13:34 28-Jul
RLL Tutorial-ette
Steve -
Looks like Steve Klein, from ISI, will be coming next week,
circa Monday. I plan to just give him an informal run through of RLL,
(spending only, say, part of Monday),
and let him then attack his particular task.
Would you like to sit in on some of these sessions -- in particular
the first ones?
The actual time is still up in the air. I'd prefer late morning,
around 11; but Steve may just be arriving then. Do you have any preferences?
Russ
PS What is your prefered mailing address?
∂12 Aug 1981 14:45-PDT greep at RAND-UNIX Re: RLL Demo
To: GREINER at RAND-AI
In-reply-to: Your message of 1 Aug 1981 2031-PDT.
Sorry I never got back in the afternoon, got sucked into a meeting.
Am now shanghaied down in LA, back in a couple of weeks.
---------------
-------